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Abstract 

SuperCollider IDE is a new cross-platform inte¬ 
grated development environment for SuperCollider. 
It unifies user experience across platforms and 
brings improvements and new features in compar¬ 
ison with previous coding environments, making 
SuperCollider easier to begin with for new users, eas¬ 
ier to teach for teachers, and more efficient to work 
with for experienced users. We present an overview 
and evaluation of its features, and explain motiva¬ 
tions from the point of view of user experience. 
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1 Introduction 

SuperCollider [McCartney, 2002] is a computer 
music system that was originally developed by 
James McCartney in the 1990s for Mac OS 
and has been ported to Linux and eventu¬ 
ally Windows after it was open sourced in the 
early 2000s. It is a modular system based 
on an object oriented programming language 
(sclang) and a separate audio synthesis server 
(scsynth) 1 . 

1.1 History of SuperCollider and its 
Coding Environments 

SuperCollider is heavily influenced by Smalltalk 
and was originally using a similar program¬ 
ming model: it strongly coupled the interpreter 
with the development environment. This in¬ 
tegrated programming environment, commonly 
referred to as SC.app was developed specifi¬ 
cally for Mac OS and therefore was not portable 
to other platforms. Nevertheless, it has been 
preserved and evolved throughout the develop¬ 
ment of SuperCollider to date, and is still in 
very wide use. 

When porting SuperCollider to Linux, Ste¬ 
fan Kersten implemented seel, a SuperCollider 

1 A multiprocessor-aware alternative to scsynth is su¬ 
pernova [Blechmann, 2011] 


editor mode for Emacs [Kersten and Baalman, 
2011], which had been the most feature-rich so¬ 
lution for a long time, as it not only supported 
syntax highlighting, but also some introspec¬ 
tion, a limited form of method call assistance 
and support for the old HTML-based help sys¬ 
tem. 

At the moment, two other editor extensions 
are part of the official SuperCollider distribu¬ 
tion: sevim (for vim) and seed (for gedit). Be¬ 
fore developing the SuperCollider IDE, one of 
the authors of this paper also developed an ex¬ 
tension for Kate (scate). 

Apart from that, there have been other cod¬ 
ing environments, either incomplete or not 
maintained anymore: sefront (a Tcl/Tk based 
editor), qcollider (a Qt-based editor) and ex¬ 
tensions for the squeak Smalltalk environment, 
the TextMate editor, Eclipse and probably oth¬ 
ers [Kersten and Baalman, 2011]. A python- 
based editor called PsyCollider [Fraunberger, 
2011] had first been distributed with the Win¬ 
dows port of SuperCollider, but later removed 
from distribution, as the code was unmain¬ 
tained, unstable and made obsolete when gedit 
and seed were ported to Windows. 

1.2 Motivation for the New IDE 

The negative aspects of the situation prior to 
SuperCollider IDE may be summarized as fol¬ 
lows: 

• The user experience vastly differs among 
the different programming environments. 

• No existing environment is working out of 
the box on every supported operating sys¬ 
tem. 

• Some environments (e.g. sevim or seel) are 
based on editors that are not very accessi¬ 
ble for beginners. 

The lack of a single cross-platform coding en¬ 
vironment is a disadvantage (particularly for ed- 



ucation of new users), because it renders impos¬ 
sible the exchange of experience among people 
who are forced to use different environments ac¬ 
cording to what is available for their operating 
system. Moreover, each programming environ¬ 
ment has to be maintained separately, and long¬ 
term maintenance turned out to be a problem. 
The scarce development resources are spread 
among different projects instead of focused on 
a single system. 

In late 2011 the authors therefore decided to 
start the development of a new IDE dedicated 
to SuperCollider (not merely an extension of a 
general-purpose code editor). The goal was to 
address all of the above issues by ensuring a uni¬ 
fied user experience across all supported plat¬ 
forms and making the IDE both easy to use for 
beginners and powerful enough so that experi¬ 
enced users would not feel the need to switch to 
an advanced editor like Ernacs. 

The choice of Qt as the underlying GUI 
framework for the IDE came naturally, as one of 
the authors had previously reimplemented the 
GUI programming classes of the SuperCollider 
language itself using Qt, which turned out to be 
quite a success. 

2 Overview of the new IDE 

2.1 System Architecture 

Since an IDE demands a tight integration with 
the target programming language, the question 
was raised immediately whether the new IDE 
should be coupled with the language interpreter 
into one process, as is the case in SC.app, or 
rather a separate process, as in existing editor 
extensions. 

Consideration of benefits and drawbacks of 
the two options brought decision in favor of 
separating the IDE from the interpreter: the 
most important benefit of this strategy is that 
the decoupling allows the IDE to survive po¬ 
tential crashes of the interpreter, and maintain 
responsiveness and control in case running some 
SuperCollider code locks up in an infinite loop. 

The major drawback of decoupling is in¬ 
creased effort for inter-process communication 
(IPC) with the interpreter. However, seel has 
proved that a powerful set of features may be 
built on top of IPC, and hence this did not out- 
weight the benefits of decoupling. 

2.2 Graphical Interface 

Thanks to the Qt GUI framework, the appear¬ 
ance and behavior of the GUI is largely equal 


across supported platforms. Figure 1 shows the 
default appearance on Ubuntu. 

The IDE has a single-window design - it fea¬ 
tures a single code editing widget at the center 
of the main window. Tabs are used to switch 
between multiple open documents. The editor 
widget can also be split horizontally and ver¬ 
tically to show more than one document at a 
time. 

Below the code editor, there is an area where 
various tool panels are displayed on request via 
keyboard shortcuts: 

• Find/Replace: a standard tool for finding 
and replacing text in the current document, 
supporting regular expressions and backref- 
erences in replacement 

• Go-To-Line: a standard tool to quickly 
jump to a line in the current document, by 
line number 

• Command Line: a tool for one-line 

SuperCollider expressions to be evaluated, 
featuring history 

Along the edges of the main window, there are 
dock areas, where other dockable widgets may be 
placed: 

• Integrated help browser 

• Document browser 

• Language interpreter output panel 

These widgets can be easily drag-and- 
dropped to different locations in the dock ar¬ 
eas, either side-by-side, or stacked on top of each 
other (with tabs appearing to switch among the 
stacked widgets). They can also be undocked 
and moved out of the main window (e.g. to 
place them on a second screen etc.), or simply 
hidden. 

The status bar on the bottom of the main 
window is used to show the state of the language 
interpreter and the default synthesis server. 
The server status box is a compact alternative 
to the SuperCollider server window, showing 
status information like CPU utilization, num¬ 
ber of running synths, groups, synthdefs etc. 

3 Interaction 

Our guidelines in interaction design were to 
minimize the amount of constantly visible con¬ 
trols, so as not to clutter the GUI, but to make 
the most used functionality quickly accessible 
via keyboard shortcuts, and advanced features 
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/******************************************************************* 

************ 

"Spacelab" -- Kraftwerk 
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******************************************************************** 

***********/ 

s = Server. default; 
s.boot; 


// SynthDefs // 

( 

SynthDef ( \bd, { | out=0 | 
var osc, env; 
osc = FSinOsc. ar( 40) ; 

env = EnvGen.kr(Env.perc(0, 0.05), doneAction: 2); 

Out.ar(out, Pan2.ar(osc, 0, env)); 

>).add; 

SynthDef ( \sd, { | out=0 | 

>ar 3233' osc2, env; 

= A'hiteNoise . ar ; 
osc2 = FSinOsc. ar( 200) ; 

env = EnvGen. kr( Env. perc( 0, 0.0 5), d oneAction: 2); 

Out.arlout, Pan2.ar( LPF.arl Mix ( [^2J, osc2]) , 12000), 0, env)); 
>).add; 
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Supercollider is an environment and programming 
language for real time audio synthesis and algorithmic 
composition. It provides an interpreted object-oriented 
language which functions as a network client to a state of 
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Figure 1: SuperCollider IDE on Ubuntu 


easily discoverable via the main menu and con¬ 
text menus - i.e. menus that pop up when right- 
clicking (or Ctrl-clicking) on a GUI element and 
offer a choice of actions relevant for that ele¬ 
ment. To combine accessibility and discover¬ 
ability the following rule is applied: as much 
functionality as possible is in the main menu, 
and each item in any menu may be assigned a 
shortcut. 

We distribute the IDE with a large set of de¬ 
fault shortcuts that cover most frequently used 
functionality by both SuperCollider beginners 
and experts, and try to adhere to shortcuts in 
other coding environments. 

3.1 System Control 

The language interpreter is started automat¬ 
ically with the IDE. Nonetheless, it can be 
stopped and restarted at will via the main menu 
or shortcuts, which is useful if code gets stuck 
in an infinite loop, or the interpreter simply 
crashes and stops by itself. 

The audio server, on the other hand, is 
not started automatically, but can be quickly 
started using a shortcut or the main menu. The 
menu includes other audio-related actions: to 
dump the node tree, show sound level meters 
and the like. All these actions may also be ac¬ 
cessed via the context menu associated with the 
audio server status box (see section 2.2 about 
the status bar). 


3.2 Code Evaluation 

Code evaluation is, naturally, the most valuable 
functionality of a SuperCollider coding environ¬ 
ment, and making it as practical as immagin- 
able is of highest importance. 

All existing coding environments support 
evaluating a line of code using a keyboard short¬ 
cut without the need to select the line. More¬ 
over, since SuperCollider code is often evalu¬ 
ated in groups of lines, there is typically support 
for enclosing such groups in parenthesis, then 
double-clicking one of the parenthesis to select 
the contents in order to evaluate them. Such 
groups of lines are commonly called regions. 

Like seel has done previously, SuperCollider 
IDE goes a step further by automatically de¬ 
tecting the region enclosing the text cursor, so 
it can be evaluated with a shortcut without the 
need to select it. The evaluation behavior is in¬ 
telligent: it will evaluate either the selection (if 
any), or the current region (if any), or the cur¬ 
rent line - where current means ‘at the position 
of the cursor’. 

Due to automatic region detection, large por¬ 
tions of code may be evaluated without se¬ 
lection. However, without any visual indica¬ 
tion, this could easily create confusion and un¬ 
certainty as to what code has been evaluated. 
Hence, another very useful feature has been im¬ 
plemented: evaluated code is highlighted, and 
then the highlighting gradually fades away. An 






















additional benefit of highlighting is in demon¬ 
stration scenarios: not only the demonstrator, 
but the audience as well knows exactly what 
code is evaluated, and when. 

4 Code Editing 

It is our goal for SuperCollider IDE to imple¬ 
ment code-editing assistance on the level of sup¬ 
port that general-purpose IDEs offer for most 
widely used programming languages. Namely, 
we consider the crucial features: syntax high¬ 
lighting, automatic indentation, automatic code 
completion and method call assistance. 

4.1 Syntax Highlighting 

Existing SuperCollider editor extensions typi¬ 
cally reuse generic support of their host editors 
for on-the-fly syntax highlighting. SC.app, al¬ 
beit the oldest and most widely used environ¬ 
ment, only updates highlighting on explicit re¬ 
quest via the user interface. 

Syntax highlighting in SuperCollider IDE has 
been implemented to update on-the-fly, and 
in a very efficient manner to never interfere 
with code typing. Attention was paid to 
strictly match the lexical rules obeyed by the 
SuperCollider language compiler. As a result, 
we have most efficient and correct syntax high¬ 
lighting for SuperCollider language to-date. 

4.2 Automatic Indentation 

The IDE automatically indents code while typ¬ 
ing, trying to mimic the most common ways 
people would indent code by hand. Automatic 
indentation may also be invoked explicitly for a 
selection of lines. 

Automatic indentation is done on the basis 
of opening and closing brackets. When a line 
break is entered, the new line is indented by 
one level if the previous line contains any open¬ 
ing brackets that are not matched with a closing 
bracket on the same line. Whenever a closing 
bracket is typed on a subsequent line, a previous 
line containing the matching opening bracket is 
searched for, and if the matching brackets are 
the first and the last ones on their lines, respec¬ 
tively, the current line is made to match inden¬ 
tation of the line above. For example: 

( 

p = Pseq([ 

Pbind( 

\degree, Pwhite(0,5,5), 

\dur, 0.1 

), 


Pbind(\degree, Pseq([6,7])) 

], inf) 

) 

As shown above, regions (see section 3.2) do 
not contribute to indentation, as is common in 
SuperCollider code. 

One current issue with automatic indentation 
remains to be addressed: indentation of line 
continuations. It is common to have one ex¬ 
pression extend over several lines; in this case, 
it is typically desired to increase indentation on 
all but the first line. For example: 

In.kr(4, 2) 

.lag(0.3) 

.linexp(0, 1, 10, 1000) 

This is currently not implemented yet; a so¬ 
lution will require enhanced grammatical anal¬ 
ysis. 

4.3 Automatic Completion 

Automatic code completion (autocompletion) 
consists of offering the user a selection of possi¬ 
ble continuations of text being typed, based on 
context. 

Array . fil| 

filename Symbol [ Qass ] 

fill [ Meta_Collection ] _ I 

fill2D [ tv1eta_Collection ] 
fill3D [ Meta’Collection ] 
fillMD [ Meta.Collection ] 

Figure 2: Autocompletion in SuperCollider IDE 

As a weakly-typed programming language, 
SuperCollider poses limitations on the possibil¬ 
ities of autocompletion, compared to strongly- 
typed languages (e.g. C, C++). Namely, it is 
not always possible to infer the type of a vari¬ 
able identifier, and hence the set of its meth¬ 
ods. We have worked in SuperCollider IDE 
towards offering completion as far as possible 
within these limitations. 

Autocompletion is offered in the following 
cases: 

• Class names: 

Sin<...> 

Since class names exclusively begin with 
an uppercase letter, it is straightfoward to 
complete them from the set of all classes. 


• Method names following class names: 

Array.<.. . > 

They are completed from the set of class 
methods of the readily-available class. 

• Method names following literals and built- 
ins 

123.<. . . > 

topEnvironment.<...> 

They are completed from the set of instance 
methods of the class inferred from the lit¬ 
eral or the built-in. 

• Method names following a variable name: 

func.<...> 

The class is not inferred, so the method is 
completed from the set of all methods of all 
classes. 

Completion of methods of known classes 
starts immediately when the dot is typed. 
One exception to this is the case of methods of 
Integer literals: it only begins after 1 character 
has been typed, or else redundant completion 
would be triggered on a dot in a Float literal, 
which proved to be a rather annoying experi¬ 
ence. 

In other cases the list of candidates may be 
quite large (the set of all classes, or all methods 
of all classes), hence completion only starts after 
3 characters have been typed. 

Although the current code base would 
easily support completion of built-ins (e.g. 
topEnvironment) and method names in func¬ 
tional notation (e.g. min (1,2)) we have decided 
to avoid that. The reason is that, formally, 
those cases would compete with other cases for 
which we currently do not offer completion: e.g. 
variable names in scope. It has been argued by 
one of the authors that autocompletion options 
may be understood (especially by novices) as 
the set of all and the only allowed options in 
a specific context, and hence misleading when 
incomplete. 

The completion menu is hidden if the cur¬ 
rently typed text matches one of the options ex¬ 
actly. In that case, the user’s intention has likely 
been met, so the menu would only present an 
obstacle to changing activity: evaluating code, 
moving to another position in code, etc. How¬ 
ever, this has been a point of debate, as it would 
be possible to automatically detect the change 
of activity and close the menu. 

Although different aspects of usability often 
demand trade-offs, we will continue to refine the 


behavior so as to maximize usefulness and intu- 
itivity of autocompletion. 

As already noted, there is potential to im¬ 
prove the domain of autocompletion to include: 

• Variables in scope: 

var abcdef; abc<...> 

• Inferring class of Array and Event literals: 

[1,2,3].<...> 

(freq: 321).<...> 

• Inferring class of variables by assignment 

x = [1,2,3]; x.<...> 

4.4 Method Call Assistance 

Method call assistance involves displaying a list 
of argument names and their default values, 
to aid entering expressions for arguments in a 
method call. 


freq = 440 phase = 0, mul = 1, add = 0 


SinOsc .a r(| 

Figure 3: Method call assistance in 

SuperCollider IDE 

It is implemented both for receiver notation 
as well as functional notation. In functional no¬ 
tation, an argument is prepended to denote the 
receiver of the message. 

The assistance is invoked when a relevant 
opening bracket ‘(’ is typed, or a comma is 
typed to separate arguments, and additionally 
with a keyboard shortcut when the text cursor 
is anywhere within the brackets surrounding the 
arguments. 

This assistance is subject to the same lim¬ 
itations as autocompletion, due to a weakly- 
typed language: to disambiguate the method, 
its owner class must be known. However, we 
have found a pragmatic solution: where the 
class can not be inferred, we let the user pick 
a class via a pop-up menu. 

Hence, the following examples will offer assis¬ 
tance directly: 

SinOsc.ar( 

123.forBy( 

...while the following will first display a list of 
classes that implement the method, then offer 
method call assistance once a class is selected: 

min( 

x.play( 

[1,2,3].inject( 




There is one special case in SuperCollider lan¬ 
guage where the method name is not explicit, 
namely an opening bracket immediately follow¬ 
ing a class name: 

Synth( 

In this case, the class method ‘new’ is implied, 
and SuperCollider IDE takes this into account 
and offers appropriate assistance. 

Once the assistance is invoked, the name 
of the current argument being typed is high¬ 
lighted, which is of great help when the num¬ 
ber of arguments is large, or the expression for 
an argument is very long. Moreover, one can 
quickly insert and cycle through available argu¬ 
ment names with a press of the Tab key, in order 
to realize argument addressing by name, as in: 

Sin0sc.ar(456, add: 1, mul: 

Once assistance has been activated for a 
particular method call, it remains active in 
the background while assistance for a nested 
method call is being performed: when the user 
finishes typing the inner call, assistance is au¬ 
tomatically displayed for the outer call again. 
This is especially useful in case assistance is 
based on explicit class selection (as explained 
above) - the selection is remembered during 
nested assistances so that method disambigua¬ 
tion does not need to be repeated. 

As can be seen from examples above, this 
assistance would also benefit from increased 
ability to automatically infer classes from text. 
Nevertheless, the described solution via explicit 
class selection will remain to be useful where the 
intended method is absolutely ambiguous. 

4.5 Editing Shortcuts 

Akin to powerful general-purpose development 
environments, SuperCollider IDE provides a set 
of actions that help navigate and edit code and 
can be assigned arbitrary keyboard shortcuts. 

Cursor movement actions include: 

• Jump to next or previous empty line 

• Jump to next or previous bracket 

• Jumping to next or previous region 

Editing actions include: 

• Move current line up or down 

• Copy current line up or down 

• Comment or uncomment current line or se¬ 
lection 


The comment/uncomment action intelli¬ 
gently uses either the single-line or the multi- 
line comment syntax, whichever is more appro¬ 
priate for the current selection. 

5 Class Library Navigation 

Within the SuperCollider community, the bor¬ 
der between system developers and users has 
always been quite fuzzy. Furthermore, writ¬ 
ing musical code often involves development of 
classes for purposes of a specific musical task 
and for personal class libraries. Jumping from 
code that uses a class to code that implements 
it is hence a frequent need. 

The SuperCollider language interpreter has 
since the beginning featured introspection into 
where each class and method is implemented, 
and referenced within the class library. Ex¬ 
isting development environments have already 
harnessed these capabilities to offer navigation 
between usage and definition via GUI. 

SuperCollider IDE attempts to exploit these 
capabilities in most practical ways. Handy 
shortcuts will pop up a dialog that lists all meth¬ 
ods whose name matches the text under cursor, 
or all methods of the class under cursor. Press¬ 
ing Return on an entry will open the file at po¬ 
sition where the selected method or class is im¬ 
plemented. The same dialog contains a search 
field which can be used to search for any class 
or method. An equivalent dialog is implemented 
also for class and method references: the listing 
contains all methods that contain references to 
another class or method. 

The shortcuts and menu actions that bring 
up these dialogs work just as well in the code 
editor, as in any other GUI element that may 
contain code: the command line, the post win¬ 
dow, and the help browser. Moreover, invoking 
help-related shortcuts within these dialogs will 
navigate the help browser to the help page re¬ 
lated to the class or method selected in the di¬ 
alog. Help and class library navigation are thus 
very efficiently linked. 

6 Help 

Recently, the traditional HTML-based help sys¬ 
tem has been superseded by SCDoc, authored 
by Jonatan Liljedahl, where help documents are 
written in a markup language developed specif¬ 
ically for this purpose and rendered to HTML 
on demand. SCDoc also monitors the filesys¬ 
tem for changes and updates its internal index 
of available documents at runtime. The benefits 



are: 


• Content is separate from style; consistent 
style can easily be applied to all documen¬ 
tation. 

• Content may potentially be rendered to 
other formats than HTML, by implement¬ 
ing different rendering components. 

• Due to on-demand rendering and filesystem 
monitoring, documentation served through 
the system is always up-to-date with re¬ 
spect to installed documents. 

Interaction with SCDoc’s on-demand ren¬ 
dering has previously only been implemented 
within the SuperCollider language, using its in¬ 
ternal GUI capabilities. The SuperCollider IDE 
is the first code editing environment to integrate 
the new help system into its own GUI. There are 
two major benefits: 

• Tighter integration with all the GUI com¬ 
ponents. 

• The last displayed document and the en¬ 
tire browsing history is preserved across 
class library recompilations and interpreter 
restarts. 

The help browser comes in form of a dockable 
widget (see section 2.2). When the user requests 
help using a related shortcut or menu action, 
on-demand rendering is performed via the SC- 
Doc system, and the resulting HTML document 
is displayed in the help browser. 

The help system is tightly connected to many 
GUI components: the help shortcut will recall a 
relevant help document for the text under cur¬ 
sor, when it is invoked within the code editor, 
the command line, the post window, the help 
browser itself, or - as noted above - for the se¬ 
lected entry in the class and method implemen¬ 
tation and reference dialogs. Example code in 
help documents may also be evaluated. Another 
benefit of integration with the IDE is that the 
shortcut for evaluation is identical to the one in 
the code editor, even when customized by the 
user. Moreover, the same shortcuts as in other 
GUI components may be used for class library 
lookup (see section 5). 

7 Sessions 

A session is a snapshot of currently open doc¬ 
uments and arrangement of GUI components 
that may be restored after the IDE is restarted. 


The IDE allows saving a number of different ses¬ 
sions and quickly switching between them, mak¬ 
ing it easy to store and recall the environment 
for different tasks. 

8 Configuration 

Many aspects of SuperCollider IDE can be cus¬ 
tomized, including: 

• behavior of automatic indentation and code 
evaluation 

• colors of the editor component and syntax 
highlighting 

• keyboard shortcuts 

The IDE also makes easy configuration of the 
SuperCollider language interpreter. Class li¬ 
brary directories to include and exclude from 
compilation can be configured via the GUI, re¬ 
moving the need to hand-edit the interpreter’s 
configuration file. There is also a handy menu 
action to open the SuperCollider startup file. 

9 Conclusions and Ideas for Future 
Development 

SuperCollider IDE has successfully reached the 
fundamental goal of providing a cross-platform 
SuperCollider coding environment. Not only 
has it integrated the individual strengths of pre¬ 
vious coding environments, but it has brought 
important improvements on its own. Immediate 
benefits arise from a unified experience across 
Linux, Mac OS X and Windows. Further¬ 
more, sophisticated user interface design and 
advanced coding assistance make it both easy 
to use by novices and a powerful tool for expe¬ 
rienced users and developers. In consequence, it 
makes SuperCollider as a whole more accessible, 
eases its education and exchange of knowledge, 
as well as focuses future development work. 

As described above, possibilities for improve¬ 
ments have been detected especially at auto¬ 
matic code indentation (4.2) and completion 
(4.3), and method call assistance (4.4), and are 
simply a matter of further work. Aside from 
that, there are many ideas for future develop¬ 
ment: 

SCDoc Editing Support 

Among the highest priority goals is support 
for syntax highlighting and editing assistance 
for the SCDoc markup language. This would 
be a very welcome aid in writing SuperCollider 
documentation, and might entice conversion of 
remaining old HTML-based documentation to 



the SCDoc format (there is a lot of unconverted 
documents in various Quarks). 

Scripting IDE Behavior 

The standard SuperCollider class library in¬ 
cludes the Document class which is used as a 
generic programming interface to various cod¬ 
ing environments. It allows for controlling the 
open documents and manipulating with their 
contents. SuperCollider IDE does not support 
this interface yet, but the support for it is of 
high priority, including its potential extension. 

Code Snippets 

An alternative code editing mode could in¬ 
troduce code snippets as individual interactive 
components. This would be an alternative for 
the current concept of regions (3.2). The snip¬ 
pets would be separated at the level of graphical 
interface, instead of code syntax, which could 
allow for instance to move them freely around a 
“desk”-like area, hide and show them individu¬ 
ally, and to evaluate their contents with a single 
click. 

Visual SynthDef and Pattern Composi¬ 
tion 

For some tasks it would be welcome to be 
able to compose SynthDefs and Patterns in a 
visual way, akin to visual programming lan¬ 
guages like PureData, Max, etc. Various dif¬ 
fuse efforts in this direction exist, mostly us¬ 
ing the SuperCollider language itself. Most 
elaborate effort is probably by Jonatan Lil- 
jedahl in his ongoing development of algoSCore 
- a SuperCollider-based successor to AlgoScore 
[Liljedahl, 2011], which includes graphical com¬ 
position of SuperCollider Patterns and Syn¬ 
thDefs. We consider potential integration of 
work in this field into SuperCollider IDE as a 
great benefit. 

Integration of User-Created GUI 

GUI creation by users would also benefit from 
a visual composition approach, as opposed to 
writing SuperCollider code. Moreover, it would 
be very practical if user-created GUIs could be 
integrated into the IDE’s own GUI, as docklets 
(2.2) or similar. 
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